Computers have proliferated into all aspects of society and increasingly form the backbone of large organisations. When a computer system fails to respond as intended, businesses are invariably unable to provide even the most basic of services. Money, reputation or even lives may be lost, dependant upon the criticality of the service, the outage time etc.
In today's increasingly competitive market-place, quality is of the utmost concern. Users' expectations are high and thus the reliability of hardware/software is especially important. Customers do not tolerate mistakes and the later a defect is discovered, the more costly it can prove to the manufacturer.
Typically software developers implement a rigourous testing regime in order to ensure that a product or system is fully operational and consistently performs according to its functional specification, before it is made available to the public. Providing efficient code is an important aspect of the testing lifecycle. Just as frustrating as software that doesn't execute as expected, is software with an unacceptably poor response time.
Performance profiling tools permit developers to measure and display program performance. Profiling in the broadest sense means the ability to monitor and trace events that occur at run-time; to calculate the cost of these events; and to apportion this cost to specific program modules. Memory leakages, performance bottlenecks etc are common problems which have to be addressed. Discovering where a piece of software spends the majority of its processing time and how effectively it uses system resources, is vital for performance fine tuning.
Recently, the Java programming language (Java is a trademark of Sun Microsystems Inc.) has risen to prominence. Java offers numerous advantages to developers. It is a platform-independent, object-orientated language, with client/server functionality. It is also a lightweight, dynamic language designed with security in mind. For all these reasons, an ever-increasing amount software is being written in Java.
A Java program executes using a Java Virtual Machine (JVM). This is central to many of the language's advantageous features, including its portability, efficiency and security. The JVM emulates a system's hardware, by stepping through a program and carrying out each instruction contained therein. Thus, the JVM need only be ported once for each operating environment and then all applications running on top of the virtual machine may execute unchanged. Furthermore, the JVM creates a layer of abstraction between a computer and the software being run on it, hence providing greater protection against malicious viruses etc.
With Java's growing popularity, performance profiling tools, which in particular monitor the performance of the JVM and applications running on top of it, have become an important issue. Sun Microsystems Java 2 software development kits (SDKs) support a performance profiling interface known as the Java Virtual Machine Profiling Interface (JVMPI). This is an interface provided to external agents written in the ‘C’ programming language which allows the agents to register with the JVM and receive notifications of events of interest to performance tools via this interface.
The JVMPI represents a considerable advance over previous Java profiling solutions as it offers a standard, extendible interface, agreed through consultation with Java tools vendors and other companies such as IBM. It defines a tool for acquiring comprehensive profiling data. Typically, the different profiling tools will have varying aims and require different information. For example, one may merely dump profile data to a trace file, while another tool may process the data selectively and interactively, and present a more sophisticated view via a graphical user interface. Tool vendors may write to the JVMPI, rather than having to code custom-built hooks directly into the JVM itself. It allows them to access consistent interfaces and events on JVM implemtnations which have a JVMPI consistent with Sun's definition. Commercially available profiling tools include Jprobe from KL Group Inc., Canada and True Coverage from Compuware NuMega, America.
FIG. 1a is a high-level schematic diagram of the operation of a performance tool profiling the JVM using the JVMPI according to the prior art. A computer 10 runs a JVM 20. A second computer 30 runs a performance tool 40 for profiling the JVM 20. It will, however, be appreciated that the performance tool 40 and the profiler agent 50 may run on the same computer (ie computer 10 or computer 30). The performance tool communicates over a tool-specific wire protocol via arrow 1 with a profiler agent 50. The agent implements all the JVMPI interface functions it requires and has to deal with the event data it receives, passing information back to performance tool 40 as required. The JVM calls this in order to enable the agent to receive events (via arrow 2) from the JVM via the JVMPI 60 at run-time. Events can include heap allocation, thread start etc., and the agent then communicates such information to the performance tool (arrow 1). On the basis of this, the tool can determine, for example, heavy memory allocation sites, unnecessary object retention, monitor contention etc. The agent sends controls and requests for more information to the JVM (arrow 3) also via the JVMPI. In order to enable this, the JVM implements a number of call-back functions. The agent may, for example, switch on or off notification of a specific event (via the EnableEvent and DisableEvent functions) in accordance with the requirements of the remote tool 40. The agent may also request notification of certain types of event such as HEAP_DUMP and MONITOR DUMP, via the RequestEvent function.
FIG. 1b shows in more detail the operation a performance tool profiling the JVM according to the prior art. It should be read in conjunction with FIG. 1a. Appendix A shows the source code for a simple profiler agent provided by Sun Microsystems. The text may be cross-referenced with the code in order to aid comprehension.
The JVM 20 is launched with the command “-XrunMyProfiler”, where “MyProfiler” is the profiler agent 50 (step 60). The agent has an entry point (method) JVM_Onload. By default the -Xrun command registers the JVM through this method in the agent 50.
Before the agent can register to receive a particular event (via arrow 2) however, a function call interface must be obtained by issuing a GetEnv call on a JavaVM pointer (step 65). This pointer forms part of the JVM environment and is responsible for retrieving a further pointer (jvmpi_interface) to the JVMPI 60. The JVMPI facilitates the enablement, requesting and general processing of events using the Notifyevent( ) and other known functions (eg EnableEvent, DisableEvent etc). Additionally the GetEnv function verifies that the current version of the JVM is supported by the JVMPI. Only versions 1.2 and later of the Java Development Kit (JDK) are compatible.
Once the jvmpi_interface pointer has been returned, the JVMPI is then initialized (step 70). The JVMPI includes the NotifyEvent( ) function which the JVM would normally invoke with each new event. However, in order for the profiler agent to receive the events rather than the profiler interface, it is necessary to redirect the pointer, and this is acheived via “jvmpi_interface->NofifyEvent=notifyEvent”. The agent code includes the notifyEvent function and this is now pointed to.
The profiler agent invokes an EnableEvent( ) function via “JVMPI_Interface->EnableEvent( )” in order to instruct the JVM to communicate a given event to the notify Event function upon occurrence of that even (step 75). Such events are then received by the profiler agent from the JVMPI (step 80).
One example of a basic, JVMPI compatible, profiling agent, is HPROF which is shipped with Java 2 SDK, Standard Edition, version 1.2 and later. It interacts with the JVMPI in order to provide the user with data either directly or through a profiling front-end (ie performance tool). Note, the front-end may either be local to the JVM or on a remote machine. HPROF simply dumps data to a report file, permitting very little control of that data. This file can however be further processed by the performance tool. The file may again be local to the JVM or on a remote machine (typically, the machine upon which the performance tool is executing).
The implementation described above has a number of drawbacks. The presence of the JVMPI in a JVM on a computer requires the JVMPI profiling agent to reside on that computer in order to register and receive events for subsequent processing. This means that for each and every tool, the JVMPI agent ‘C’ code must be ported to the target computer, compiled, debugged and shipped by the tool writer. In practice, this has meant that Java 2 performance tools have not supported all the computer platforms which have JVMPI implementations—in just over a year after Java 2 launched in December 1998, only Windows NT and Solaris platforms have third party tools working with the Sun JVM. Support is not, for example, provided for many platforms such as OS/390 from IBM and it may be difficult to find the skills and machines to allow the tools vendors to implement their tools on all platforms. As Java becomes established as a major programming language, the availability of performance tools on both development and deployment computers becomes a prerequisite for business-critical applications.
Furthermore, all performance tools perturb the performance characteristics of the system they are measuring, unless they are built in and cannot be disabled. The events which the JVMPI is capable of generating that are of interest to performance tools, such as method entry and exit, occur very frequently and can accumulate high data volumes. Additionally, many 3rd party tools offer ‘real time’ visualization of Java performance data as it is being generated. If the computer being measured is the same one as is being used to display the data, the perturbation of the data can, once again, be considerable.
The IBM Corporation recently announced the release of VisualAge Micro Edition. This provides an integrated development environment for building end-to-end embedded systems. In other words, it enables the development of applications connecting small, resource constrained devices, such as personal digital assistants (PDAs) and cell phones, to enterprise back-end systems over the Internet.
VisualAge Micro Edition is shipped with a profiler for monitoring the performance of a JVM running within an embedded system, as well as applications executing on top of the virtual machine. This profiler can either sit directly on the embedded device or be run remotely from a development workstation. A remote setup has the advantage that the minimum of load is placed on the embedded device.
FIG. 2 is a schematic diagram of such a remote profiler configuration. An embedded device 100 runs a JVM 110. A computer 130 runs a profiler agent 140. The JVM receives control commands from the agent and in return the agent receives events from the JVM. The agent communicates the information received from the JVM to a performance tool 150.
While the profiler agent communicates remotely with the JVM 110, it does so via a direct entry-point. In other words, the JVM 110 itself has been specially modified to support the Profiler Agent 140. The JVMPI and all the advantages it provides have been dispensed with in this solution. Although the agent code does not have to be ported to the embedded device, it does have to be compiled and debugged by the tool writer in order to be compatible with the specific JVM implementation.
In my own work leading up to the invention described below. I considered providing remote access for profiling agents via the JVMPI to achieve greater portability. FIG. 3 shows the constituent parts of what I considered. A computer 207 runs a profiling agent 280 which profiles a JVM 200 running on a second computer 205. The JVM 200 sends events via a JVMPI 210 to a proxy 220. Proxy 220 is ‘C’ code and is responsible for receiving the profiling data generated by the JVM 200. In order to communicate this to computer 207 and ultimately the profiling agent 280, the event flow has to re-enter Java via a second JVM 230. It does this using the Java Native Interface (JNI) 225. This re-entry is so that existing java mechanisms can be used to transport the events to the profiling agent running on computer 207. Thus I believed transparency could be achieved, this being the primary aim. The intention is to have the profiling agent write to the JVMPI interface, whilst being completely unaware as to whether it is running locally or remotely.
In order to transmit events to the profiling agent there is a java proxy 235 running within JVM 230. This calls a remote method (java proxy) 265 running on computer 207 via a Remote Method Invocation (RMI) interface 255. Thus an existing protocol, Java Remote Method protocol (JRMP), is used to communicate with computer 207. Remote Method (Java Proxy) 265 runs within a third JVM 260 and receives the events. As disclosed, these are then communicated via the JNI 226 to the profiling agent 280. Intelligent caching of data is built-in, in order to minimise the network traffic.
After doing this work, I concluded this scenario would not achieve its primary aim of transparency. The profiling agent would realize that the events it receives from JVM 226 had indeed come from its local machine 207 rather than the true originator, JVM 200. This is because JNI interface 226 is presented to the profiling agent, rather than a JVMPI interface as should be the case. I stopped the described work without revealing it publicly and proceeded with completion of the invention described herein.